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METHOD AND APPARATUS FOR CENTRAL COORDINATION OF DATA 
TRANSMISSION BETWEEN A TRANSMITTING AND A RECEIVING 
NETWORK ELEMENT 

5 CLAIM FOR PRIORITY 

This application claims priority to European 
Patent Application No. 00117012.5 filed on August 8, 
2000, the disclosure of which is incorporated by- 
reference in its entirety. 

10 

TECHNICAL FIELD OF THE INVENTION 

The invention relates to communication in a 
network using different protocols and/or data 
interchange formats. 

15 

BACKGROUND OF THE INVENTION 

In recent years, commercial information 
providers have suddenly shown increasing interest in 
the Internet. This development is due primarily to the 

20 flexibility of information interchange, and to the 
comparatively low costs. For example, the Internet can 
very easily be used to make information available 
worldwide quickly and cheaply without the interposition 
of the central entity, or to offer completely new 

25 services. This is based on the distributed 
communication architecture of the Internet. Standard 
guidelines are difficult to implement in this case. In 
the areas of data coding, data transmission and data 
presentation, this freedom has led to a large number of 

3 0 industry standards or quasi - standards , which have been 
developed in parallel. This has in turn resulted in 
products which use different formats and methods for 
interchanging data and for data representation. 
Examples of this are applications on Notebooks (PCs) , 

35 palmtops or mobile telephones, which communicate with 
one another via the Internet. This trend is being 
promoted primarily by rapid innovation cycles, the wide 
range of products, increased specialization and a 
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downward compatibility which is often required in the 
communication area. 

At the moment, every application/terminal 
provider is forced to support a large number of 
5 standards or relevant quasi -standards, in order to 
achieve compatibility with the products from other 
manufacturers. Compatibility in this case includes the 
communication protocols, the formats for the data that 
are interchanged, and the representation of such data 

10 in the terminal. These factors are frequently 
negotiated at the start of the communication process. 
Figure 2 shows the architecture of one such system. Two 
application types ATI, AT2 and a number of terminals 
A, B, C are described. The connecting lines within the 

15 figure show the data flow. The converters Ula to U2c 
are responsible for format conversion to match the 
capabilities of the respective terminal and the 
application. A characteristic feature of this 
architecture in this case is that each application has 

20 its own converter. Frequently, this is even integrated 
in the application. 

This has resulted in the growth of the 
combinational problem of a large number of applications 
in these terminals needing to support an ever greater 

25 number of standards for data transmission, coding and 
presentation. This is very costly for the 
manufacturers . 

For this reason, neither an application nor a 
terminal can support all the existing standards, for 

3 0 both financial and technical reasons. Each application 
manufacturer restricts himself /herself to those 
standards which promise him the greatest turnover. 
Niche products or older appliances therefore cannot use 
new applications. 

35 

SUMMARY OF THE INVENTION 
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In one embodiment of the invention, there is a 
method for central coordination of data transmission 
between a transmitting network element and a receiving 
network element. The method includes, for example, 
requesting a converter service from a converter 
coordinator using the transmitting or receiving network 
element, selecting the converter service using the 
converter coordinator and performing a data conversion 
on the data, wherein the transmitting and receiving 
network elements do not have compatible data or 
transmission formats. 

In one aspect of the invention, the 
transmitting and/or receiving network element is a 
terminal . 

In another aspect of the invention, the 
transmitting and/or receiving network element is an 
application. 

In still another aspect of the invention, the 
method includes sending a report via the converter 
service to the network element which produced the 
request . 

In yet another aspect of the invention, the 
method includes sending a report via the converter 
service to the transmitting network element, to the 
receiving network element and to the selected 
conversion service. 

In another aspect of the invention, the 
report includes information about the interchange 
format to be used by the transmitting and receiving 
network elements. 

In still another aspect of the invention, 
data is transmitted between the transmitting and 
receiving network elements via the converter without 
any further action by the converter coordinator. 

In another embodiment of the invention, there 
is an apparatus for central coordination of data 
transmission between a transmitting network element and 
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a receiving network element. The apparatus includes, 
for example, at least one converter which is registered 
and at least one transmitting or receiving network 
element which receives a request for a converter 
5 service, wherein the apparatus selects one of the at 
least one registered converters. 

In one aspect of the invention, the selected 
registered converter is sent as a response to the 
requesting network element. 
10 In another aspect of the invention, the 

selected registered converter is sent as a response to 
relevant network elements. 

BRIEF DESCRIPTION OF THE DRAWINGS 
15 The invention will be explained in the 

following text with reference to exemplary embodiments. 
In this case, in the figures, in which: 

Figure 1 shows an exemplary system architecture 
with central converter management . 

2 0 Figure 2 shows the architecture of a previous 

system (prior art) . 

Figure 3 shows a first example of the 
information flow between an application, terminal and 
central entity. 

25 Figure 4 shows a second example of the 

information flow between an application, terminal and 
central entity. 

Figure 5 shows a specific exemplary embodiment. 

3 0 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The invention specifies a solution for the 
problems mentioned above. The invention supports a 
large number of possible applications and terminal 
types, with a minimal number of converters. 
35 Conversion functions (referred to as media 

converters in the following text) are, according to the 
invention, offered as a separate service for widely 
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differing formats and protocols in the network. 
Applications then no longer need to support every 
standard, but can use the appropriate conversion 
service, if required. This shortens the development 
5 times and leads to better interoperability with and 
between terminals from different manufacturers, since 
each manufacturer does not normally really implement 
each format . 

Terminals and applications which wish to 
10 communicate with one another need to agree on a common 
protocol and data interchange format . In the past , the 
information which was stored in the terminals was 
sufficient for this purpose: each terminal knew which 
protocols and data interchange formats it supported; 
15 the selected protocols/data interchange formats had to 
be within the scope of these selection options. A 
common protocol or data interchange format was 
negotiated directly between the respective terminal and 
the application. 

20 

With the provision of converters in the 
network, it is possible to consider a new dimension in 
the negotiation of the protocol and data interchange 
format - the range of available converters and their 
25 capabilities for conversion of one protocol or format 
to another. The terminals/applications do not have this 
knowledge . 

A central entity is therefore introduced in the 
invention. The available converters register with this 

30 entity and store information about the 

protocols/formats which they can convert to one 
another. The central entity manages this information 
and makes it accessible to applications and terminals. 
The information interchange could, for example, be 

35 based on a simple question and answer mechanism, and 
many implementation options for this purpose are known 
to persons skilled in the art. 
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Various scenarios are feasible for negotiation 
of a common data interchange format between terminals, 
examples of which are explained in the following text. 

An application/terminal makes contact with 
another terminal/application. After receiving the 
service request, the terminal or application checks 
whether its own capabilities are compatible with those 
of a partner, or whether a converter service is 
required for information interchange. In the latter 
case, a terminal then turns to the central entity and 
requests the provision of a suitable converter. 

The central entity: 

uses predetermined criteria to select a suitable 
converter service, and informs the terminal or 
terminals/application or applications and the 
converter of the interchange formats . The service 
communication then takes place directly, without 
the involvement of the central entity, or 
informs the requesting terminal/application of the 
possible converter services. The 

terminal/application uses its own criteria to 
select a suitable converter service, and informs 
the partner- terminal /partner- application and the 
converter of the interchange formats. 

However, the central entity is not necessarily 
a universal service provider but a specialized provider 
of converter services which is autonomously able to 
select a suitable converter service from a range of 
converter services, on the basis of criteria. The 
infrastructure - central entity, media converter, 
terminals and applications - can be constructed, for 
example, using the JINI technology. 
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Some of the advantages of central converter management 
are : 

manufacturers of applications/terminals need no 
5 longer support a wide range of standards for data 

transmission, coding and presentation, 
manufacturers of converters and the central 
entities can - now, since converters are no longer 
produced exclusively for one application 
10 concentrate on addressing the major area of 

terminals, which was previously ignored for 
financial/technical reasons (market 

range/feasibility) . 

15 The management of converters in a central 

entity in the network (for example, provision by a 
central entity) makes converters available to 
applications/terminals . Applications and converters can 
thus be produced more economically, and can offer a 

2 0 wider range of protocols and data interchange formats 
that are supported. 

Figure 1 shows how each converter 1 , 2 can be 
used by a number of applications Typl, Typ2 . The thick 
lines illustrate the registration relationships to the 

25 central entity. The dotted lines indicate the data flow 
between applications and terminals A, B, each of which 
includes a converter. A practical application based on 
the general system architecture and Figure 5 will be 
explained in the following text. 

30 In the Internet, the "E-mail" service is 

offered, which allows documents to be interchanged. 
In this example, an application Typl (a mail server) 
and a terminal A (for reading and writing the E-mail) 
are communicating with one another. The E-mail is 

35 located on the mail server, for example as an MIME 
coded (Multipurpose Internet Mail Extensions) ASCII 
text (American Standard Code for Information 
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Interchange) at 1, and one component of the E-mail 
(attachment) is a soundfile. The terminal may be a 
mobile terminal which supports the data interchange 
format WML1 . 1 (Wireless Markup Language) in accordance 
5 with protocol standard WAP 1.1 (Wireless Application 
Protocol) . 

The terminal registers with the mail server and 
finds that new mail has arrived at 2 . The terminal 
decides to download the mail from the mail server. The 

10 mail server reports to the terminal that it is 
necessary to reproduce soundfiles (in accordance with 
the wav Standard) and to support POP3 (Post office 
protocol) or FTP (file transfer protocol) for 
transmission. In this case, the terminal is not able 

15 to do this. So, the server and terminal cannot find a 
common format in which the soundfile could be 
transmitted from the E-mail by the server to the 
terminal, and could then be reproduced by that 
terminal . 

20 The terminal 3b (or the mail server 3a) 

requests a provision from the central entity. The 
capabilities of the terminal and mail server are 
reported to the central entity, including the fact that 
the terminal is a mobile telephone and supports 

25 telephony. 

The central entity selects a converter which is 
able to receive sound files by FTP, to set up telephone 
connections, and to reproduce said sound files via the 
voice channel of such a connection. 

3 0 The mail server transmits the sound file by FTP 

to the converter at 4, which sets up a telephone 
connection to the terminal and reproduces the sound 
file via this connection at 5. 

Figure 3 shows a first example of the message 

35 flow between an application, terminal and central 
entity. A conversion service is registered with the 
central entity such that data can be interchanged in 
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any desired format between two terminals or 
applications. First, an attempt is made to interchange 
such data by direct communication between the 
terminal/applications. However, if it is determined 
5 that the transmission formats are not compatible, the 
central entity is requested to provide a suitable 
converter service. The central entity uses the 
conversion services registered with it to select a 
suitable service. The central entity then informs each 

10 of the units involved. The transmitting application or 
terminal transmits the data to the conversion service, 
which converts said data and then passes it on to the 
receiving application. 

Figure 4 shows a second example of the 

15 information flow between an application, terminal and 
central entity. The procedure corresponds to that 
illustrated in Figure 3 . However, the central entity 
informs the requesting unit, which in turn informs the 
other units involved: the conversion service and the 

20 receiving application or terminal. The transmitting 
application or terminal transmits the data to the 
conversion service, which converts such data and then 
passes it on to the receiving application. 
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